This repository was archived by the owner on Feb 4, 2023. It is now read-only.
Allow captive portal to run more than once by closing dnsServer cleanly. #49
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
I noticed that if the Config Portal is started more than once by calling
startConfigPortal(...)without rebooting the device, then only the first instance functions as a captive portal; at least within 10 seconds of each other.This is due to the fact that the
WiFiUdpobject inDNSServer.his never told tostop(), and so the OS holds on to port 53. The result ofdnsServer->start(DNS_PORT, "*", WiFi.softAPIP());inESPAsync_WiFiManager::setupConfigPortal()is never checked; this will returntrueif it can secure the port,falseotherwise. If you check the result ofdnsServer->start(...)for the second call tosetupConfigPortal(), you'll see that it returnsfalse.The easiest way I found to fix this was to replace
*dnsServer = DNSServer();instartConfigPortal(...)withdnsServer->stop();. This will correctly finalise theWiFiUdpobject and free up the port for next time.I'm running this library on a ESP8266 D1 Mini, through PlatformIO.